Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spreadinterponly (CPU and GPU) #602

Open
wants to merge 17 commits into
base: master
Choose a base branch
from
Open

Spreadinterponly (CPU and GPU) #602

wants to merge 17 commits into from

Conversation

ahbarnett
Copy link
Collaborator

@ahbarnett ahbarnett commented Jan 8, 2025

This is a proposal for how a convenient access to the spread/interp task is possible via the FINUFFT/cuFINUFFT interface. (since spreadinterp module is not part of our API). It is based on @chaithyagr PR #599 for the new CPU opts field. And the GPU s/i-only is already part of 2.3.1 and master.

Design discussion:

I feel that the GPU spreadinterponly interface has to be tweaked so that upsampfac controls the kernel shape. This would also apply to CPU. Currently GPU forces upsampfac=1.0, but under the hood uses the kernel for the default upsampfac=2, which makes no sense.
Eg, I would like to be able to set upsampfac=infinity, which gives a certain kernel shape needed in Ewald methods.

I will hash this out here. Comments welcome.

Tasks:

  • clean up CPU spreadinterponly=1 logic
  • add the new opts field to all language interfaces and check
  • example which demos it (1D)
  • add tester to CI (1D)
  • docs CPU
  • MATLAB demo CPU
  • Revisit gpu_spreadinterponly=1 and edit logic so upsampfac is respected rather than forced to be 1.0
  • GPU doc copying CPU doc

@ahbarnett
Copy link
Collaborator Author

@chaithyagr If you look at the example, tester, and docs/opts.rst you will see my proposal for the cpu spreadinterponly=1 implementation. See what you think. If you are not unhappy - let me know - I will apply this to GPU too - the difference being you would not have to set upsampfac=1 to use it, rather would set it as with a NUFFT. This is really the only way I can see it working, without breaking the API.

I still would be curious how you guys access the actual kernel function used, in your DCW for MRI application...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants